IBIS Macromodel Task Group Meeting date: 22 September 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: * Michael Mirmak Kinger Cai Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Todd Bermensolo * Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that Randy had suggested that the "IBIS-ISS parser" entry in the topic bin list could be removed because the Interconnect task group is looking into it. ------------- Review of ARs: - Michael to send a second draft of the [Clock Pins] BIRD proposal. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the September 15 meeting. Michael moved to approve the minutes. Lance seconded the motion. There were no objections. ------------- New Discussion: New Clock-Data Pin relationship BIRD [Clock Pins]: Michael Mirmak briefly summarized the [Clock Pins] BIRD draft, which had been introduced and described at the previous meeting. - New keyword [Clock Pins] - Each entry (row) has three columns - The first two columns contain pin_names from the [Pin] list. - The third column defines a timing relationship between the two. Michael said the goal is to tell the tool/user that there's a timing relationship between pins. He said that based on feedback from the first draft he had added language to deal with the case of [Diff Pin] pairs. Based on feedback from Bob he also added text to deal with [Model Selector]. He reiterated that his hope is to focus on this new keyword alone and get this timing relationship concept into the specification as soon as possible. He said this concept can't be included at the [Model] or .ami level. Its immediate goal is to facilitate the clock pin - data pin relationship needed by DDR. It does contain the third column and some allowed values for it, but the third column is currently just providing a descriptive string with no other meaning defined. Long term he expects an additional BIRD and perhaps additional keywords to be added to fully define the information in the third column. For now it's a place holder, so we don't get bogged down for a long time defining those relationships. Randy asked if we need to think this through carefully to make sure this keyword will stay relevant and not become obsolete as the future changes are made. Michael said this was a good question, and this was why he had tried to make this keyword as simple as possible. We would need a new BIRD to define the timing relationships and expand upon them, but it shouldn't affect this BIRD. He noted that if we get into more complex timing relationships, for example, defining a relationship amongst more than a pair of pins (or pair of diff pin pairs), we might have to revisit this BIRD then. He said he wasn't expecting this to happen. Michael noted that there had been some questions about the relationship with the package and whether the timing relationships might have to be at the pin or the pad, but this could be dealt with later. Randy asked if this was related to the Si_location Sub-param. Michael said it was, and the problem with Si_location is that it is specified for the entire [Component]. Since different interfaces specify pin level or pad level timing, a component wide Si_location might not be sufficient. He said that the process of defining these timing relationships in column 3 might be the beginning of a change to address this shortcoming. We might define something that overrides Si_location, or perhaps define the concept of clock pins and clock pads. Arpad said the discussion had moved into timing and timing locations, and he didn't think we needed to get into timing yet, as this BIRD only defines a logical clock-data relationship not the timing relationship. Michael agreed but said Randy is suggesting that [Clock Pins] strongly implies that the pin is the timing location. Arpad asked if this proposal would be able to handle splits and joins if IBIS or EMD ever allowed that and got away from the one-to-one pin to pad mapping. For example, he brought up a RAMBUS example Walter had described where two clock pins connected to the same pad (e.g., clock pin1 connects to pad1 and then back out to clock pin2). Michael said the current proposal would support that by letting the clock on one pin be an input and the clock on the other pin be an output. He noted that right now in this BIRD the column three data is not really cross checked with the types of pins, only the relationship and perhaps the directionality can be checked. Perhaps the relationship would be Clock_Skew in this case. Currently the first entry has to be a clock, the second entry could be a clock but is most likely data, and the third entry is just a string. Randy said that as written, since the BIRD doesn't talk about timing, we are okay for now and can expand things later. Bob and Fangyi asked if it was possible for a clock pin to appear in column 1 (this is required), and a clock pin to also appear in column 2, and for the pin in column 2 to appear as the clock pin in column 1 on another row. Fangyi explained this scenario as having a clock pin defined for a data pin, but that clock pin is itself derived from a reference clock. Michael referred to this sentence in Usage Rules: Entries in the second column shall not appear on more than one line under the keyword. He said this sentence prohibited the scenario Bob and Fangyi asked about, but that we could relax this restriction. He noted, however, that history had shown us that it's much easier to define something narrowly to start with and then expand it later if necessary. Bob said that historically IBIS had decided many years ago to keep timing separate from the IBIS buffer. He said they'd even developed a separate RAIL (Rules Augmented Interconnect Layout) specification (circa 1996) and parser, but it wasn't widely adopted by the industry. Michael said Bob raised a good point, a limitation of putting timing information in a [Model] is that a given [Model] could be applied to multiple interfaces with different timing relationships. We want to avoid having timing in the [Model] and keep it at the interface ([Pin]) level. Bob noted that it's legal for a [Model Selector] to include [Model]s of various types. Michael agreed and said language in the proposal explicitly states that it's compatible with [Model Selector], but it notes that it may be possible to declare timing relationships that may be inappropriate if certain [Model]s are selected. He said this can't result in a parser error because it's possible other models in the selector would be valid. Perhaps the parser or tool could issue a warning if a model type incompatible with the timing relationship were seen. Fangyi asked Michael for definitions of the three relationships defined in the proposal. Michael said the relationships' definitions are somewhat implied by the description of the allowed directionality (input/output) of the pins in column 1 and column 2. For Clock_to_Out and Setup_Hold, the first pin is some type of clock and the second pin is some type of data. Clock_to_Out - first pin is incoming clock and there is some delay before the data appears at pin 2. Pin 1 input or bi-directional. Pin 2 output or bi-directional. Setup_Hold - clock is on pin 1 and there's a setup and hold relationship with the data pin 2. Pin 1 input or bi-directional. Pin 2 input or bi-directional. Clock_Skew - pin 1 is a clock and pin 2 is a clock and there's a delay between them. Pin 1 output or bi-directional. Pin 2 output or bi-directional. Lance asked if there were rules to enforce use of the right Model_types for the two pins. Michael said that the relationships imply a directionality and the parser could report an error if an incompatible type were used, for example, if an output Model_type were used with either pin of a Setup_Hold relationship. Randy asked if Setup_Hold, for example, was envisioned for a write clock where the strobe is input or bi-directional and the data is bi-directional. Michael agreed that was the intent. Fangyi asked Michael what types of signals he envisioned on pin 1 and pin 2 for the Clock_Skew case. Michael said one example might be a mux or multi-clock chip where you need to specify timing limits of the relationship between one output and another. Randy suggested a register DIMM example with a clock in and four clocks out. Michael agreed this would be one example. Fangyi asked if the relationship defined the signal path in the IC or just the timing relationship in the measurement. Michael said the goal was only to state the timing relationship in the measurement. He said that historically, for single-ended memory simulation, IBIS had no timing, jitter, etc., information at all. All of this had to be provided to the user outside of IBIS somehow. Now the goal of this proposal is to start to pull that information back into IBIS. We now have BIRD 204, which allows for a DQ buffer that needs to be latched by an input DQS. We currently have no way in IBIS to tell the user/tool where that DQS signal is coming from. This proposal wants to fill that void. Michael said he was open to other ways of providing that information, but he wanted to avoid getting bogged down in the details of the timing relationships themselves. Arpad asked about [External Circuit] and referred to figure 30 on page 150 of IBIS 7.0. He noted that pin 4 is the clock for the data pin 3, and he asked if this proposal could be used to give pin relationship information for [External Circuit] calls. Randy and Bob noted that it could be more difficult to do consistency checking with [External Circuit], as it's harder to infer directionality. Arpad said use of a D_to_A, for example, implies it's an output or I/O. Randy asked if the parser currently checked that. Michael said that the high-level answer to Arpad's question is that there are no conflicts between [Clock Pins] and [External Circuit], but nothing in this BIRD says to cross check the directionality with [External Circuit]. Michael said [Clock Pins] is optional, so there's no requirement to make it comprehensively support [External Circuit]. Randy suggested it would simplify the BIRD if we simply stated that it is not cross checked with [External Circuit]. Ambrish noted Michael's stated primary goal of getting the timing relationship concept into the specification. He asked why column 3 is included at all in this BIRD. Michael said this was a good question and that he was open to the suggestion to eliminate it. However, without column three there are several concerns: the parser can't do directionality checking, the third column does provide some architectural information (per Fangyi's earlier question), and the complication of having a subsequent BIRD have to add a column 3 later. Fangyi said at this point column three is really more for the parser than anything else. Michael gave himself an AR to consider five possible change suggestions from this meeting: - "clock pads" per Randy. - rails per Bob. - whether the proposal should allow clocks to appear in column 1 and later in column 2 per Bob and Fangyi. - define what the relationships really mean per Fangyi. - at least state that the directionality of [External Circuit] can't be cross checked per Arpad and Randy. - Randy: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Michael to create a third draft of the [Clock Pins] BIRD proposal. ------------- Next meeting: 29 September 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives